Static analysis refer to statically analyzing computer code to monitor whether it meets uniform expectations about reliability, performance, and maintainability. Static code analysis provides a foundation for producing solid code by exposing structural errors and preventing entire classes of errors. Generally, an effective static analysis encompasses static source code (pattern based) analysis, data flow static analysis, and code metrics analysis.
Pattern-based code analysis monitors whether code follows industry-standard or customized rules for ensuring that code meets uniform expectations around security, reliability, performance, and maintainability.
Data flow static analysis provides automated detection of runtime errors without requiring the software to actually be executed. It statically simulates application execution paths, which may cross multiple units, components, and files. Data flow static analysis can automatically detect potential runtime errors such as resource leaks, NullPointerExceptions, SQL injections, and other security vulnerabilities. This enables early and effortless detection of critical runtime errors that might otherwise take weeks to find.
While static source code is an error prevention practice, data flow static analysis is an error-detection practice. The main difference between static source code analysis and data flow static analysis is that with pattern-based static code analysis, one can be ensured that certain classes of defects will not occur as long as the coding constructs known to cause these defects are found and fixed. With data flow static analysis, defects that could actually occur when real application paths are exercised are identified—not just dangerous coding constructs.
Code metrics analysis calculates various metrics for computer code to help assess code base and monitor changes. It identifies brittle or overly-complex code that could impede agility or reuse. It also helps better understand code complexity and assess the potential impacts of an anticipated code change.
Static analysis has been applied to conventional programming languages, such as C++ and JAVA™ for analyze the structure of the language. However, with ever growing popularity of business process, service oriented, and web service orchestration languages, there is a need to not only test the structure of the language, but also, test the behavior of the business process or enterprise.
SOAP, originally stood for “Simple Object Access Protocol”, but it now refers to a more generalized protocol for any service oriented protocol. SOAP is currently an XML-based messaging framework for exchanging structured and typed information between peers in a decentralized, distributed environment. Extensible Markup Language (XML) is a meta-markup language for describing data objects. SOAP is typically implemented in XML and relies on XML namespaces and XML schemas to define document types that describe messages. SOAP describes a simple messaging (request/response) mechanism (for example, Remote Procedure Calls (RPC)). That is, a SOAP client sends a request (e.g., a RPC request) to a SOAP server. The SOAP server then replies by sending a response (e.g., a RPC response) to the SOAP client.
Web Services Description Language (WSDL), also typically implemented in XML, is used to describe the types of requests accepted by a particular Web service. It is used to communicate meta-information about the Web service and, as such, is not strictly necessary for invoking the Web service itself.
Business Process Execution Language (BPEL) provides a language for Web service orchestration in terms of processes and activities. The activities include primitive activities such as receiving and replying to messages, invoking services, and simple data manipulation as well as structured activities such as sequence and flow that can be hierarchically arranged to create sophisticated business logic.
BPEL depends on WSDL (Web Service Description Language), in which all services that are accessed through BPEL are done so through the abstract interface described in WSDL. Adherence to this abstraction is part of what facilitates easy integration of heterogeneous components in BPEL, because it matters not what language or platform a particular component is implemented with, so long as it exposes its functionality as a service described in a WSDL.
Typically, BPEL processes need to be executed by a runtime engine that supports a number of requirements, including native support for Web service standards as well as asynchronous messaging, process persistence, and transactional models consistent with long-term processes.
XPDL (the XML Process Definition Language) is an emerging standard in the area of Business Process Management (BPM). XPDL is a standardized format for interchanging business process definitions between different workflow products (e.g., different modeling tools and management suites). At this point, it seems that XPDL is emerging as an intermediate language that most systems will use to describe business processes.